TOCTOU race between depth test and color write

wp.atomic_min establishes the winning depth value atomically, but the subsequent color write is unprotected. Two threads rendering overlapping wireframe segments at nearly identical depths can both satisfy z <= old_depth (both see the unmodified value before the other's atomic_min completes), and then both write to rgba[index] in an unordered manner. The color stored in the buffer will correspond to whichever thread wrote last, which need not match the thread that actually holds the minimum depth after both atomic_min calls settle. For the point cloud path the two-phase key/resolve scheme avoids this problem; the same pattern should be applied to wireframe pixels, or the atomic operation should cover the combined depth-color update.

wp.init() executed at module import time

Calling wp.init() at the top level of _warp_impl.py means it runs the moment any rendering submodule is imported — including users who only want the pure-PyTorch ScalarFieldToRGBA or VectorFieldToRGBA torch backends. In environments without CUDA (CI runners, CPU-only inference containers) this will either error out or trigger slow device enumeration. The initialization should be deferred to first use, e.g., inside the @torch.library.custom_op implementations or behind a lazy try/except guard.

Input validation skipped on CUDA devices

Both _camera_basis and _bounds_tensor guard their invariant checks with if forward_raw.device.type == "cpu", so on CUDA the checks are never performed. Passing eye == center (degenerate forward vector), up parallel to the view direction (degenerate right vector), or bounds_max <= bounds_min in any dimension will silently produce NaN or zero vectors that propagate through the kernel, yielding a black/corrupt render with no diagnostic. The same CPU-only pattern is repeated in _bounds_tensor (line 88). The validation should be unconditional, or the tensors should be moved to CPU just for the check.

Hardcoded range(8192) cap silently truncates long line segments

_draw_line_depth_tested loops for step in range(8192) and breaks when step > steps. For an edge whose projected screen-space extent spans more than 8192 pixels (e.g., a near-clipped edge at very high resolution or a very small FOV), the line will be silently cut off partway. The limit is invisible to callers and produces no warning. Consider deriving the cap from max(image_width, image_height) passed into the kernel, or at minimum documenting the constraint.

Wireframe clips entire edge when any endpoint is outside the clip range

_wireframe_render_kernel returns early if either endpoint has s[2] <= near or s[2] >= far. A segment where one vertex is behind the camera and the other is in front will be silently dropped entirely rather than clipped. For scenes with edges that straddle the near plane this produces visually missing lines. The standard fix is to perform a parametric clip of the segment against the near/far planes before rasterizing.